Nice fix for the punycode case. Before this lands, one realistic case still misparses, and a slightly simpler shape closes it.

Where can -- appear in a hostname?

Only two places:

1. As a schema separator (coder-vscode.<host>--<owner>--<workspace>--<agent>).
2. Inside a punycode label (xn--<encoded>) somewhere in the domain.

Coder's UsernameValidRegex forbids -- in usernames, workspaces, and agents, and xn-- is the only IDN ACE prefix IANA has allocated. That's the whole space.

Apex punycode still misparses

A deployment served at the apex of an internationalized domain (e.g. https://xn--p1ai/) produces coder-vscode.xn--p1ai--owner--ws. Splitting gives ["coder-vscode.xn", "p1ai", "owner", "ws"]; parts[1] is p1ai with no dot, so the merge loop exits immediately and p1ai becomes the username. Rare but real.

Simpler parser

Scan forward, growing the prefix one segment at a time, and accept the first boundary where the prefix is valid and the remaining tail is a valid <owner>--<workspace>[--<agent>] or <owner>--<workspace>[.<agent>]. A valid prefix is coder-vscode or coder-vscode.<...> and does not end in .xn (which is the only way -- can legally appear inside a domain, so ending in .xn means we cut a punycode label).

const SLUG = /^[a-zA-Z0-9]+(?:-[a-zA-Z0-9]+)*$/;

function isValidPrefix(prefix: string): boolean {
  if (prefix === AuthorityPrefix) return true;
  return (
    prefix.startsWith(`${AuthorityPrefix}.`) && !prefix.endsWith(".xn")
  );
}

export function parseRemoteAuthority(authority: string): AuthorityParts | null {
  const sshHost = authority.split("+")[1] ?? "";
  if (
    sshHost !== AuthorityPrefix &&
    !sshHost.startsWith(`${AuthorityPrefix}--`) &&
    !sshHost.startsWith(`${AuthorityPrefix}.`)
  ) {
    return null;
  }

  const parts = sshHost.split("--");

  for (let i = 1; i <= parts.length - 2; i++) {
    const prefix = parts.slice(0, i).join("--");
    if (!isValidPrefix(prefix)) continue;
    const tail = parts.slice(i);

    // 4-part: <prefix>--<owner>--<workspace>--<agent>
    if (tail.length === 3 && tail.every((p) => SLUG.test(p))) {
      return build(sshHost, prefix, tail[0], tail[1], tail[2]);
    }

    // 3-part: <prefix>--<owner>--<workspace>[.<agent>]
    if (tail.length === 2 && SLUG.test(tail[0])) {
      const [workspace, agent = ""] = tail[1].split(/\.(.+)/);
      if (SLUG.test(workspace) && (agent === "" || SLUG.test(agent))) {
        return build(sshHost, prefix, tail[0], workspace, agent);
      }
    }
  }

  throw new Error("Invalid Coder SSH authority");
}

Every existing case parses identically

False negatives

The only input this can reject incorrectly is a deployment whose domain ends in a label literally named xn (e.g. something.xn). IANA reserves the xn-- space, url.domainToASCII does not produce bare xn followed by separator content, and no real TLD or registrable label of xn alone exists. So the failure mode is a label that essentially cannot legally be reached.

Side benefit

The slug regex also rejects empty names and names ending in - that the current parser passes through, so input validation tightens up at the same time.

Happy to push this as a follow-up commit on this branch.